Follow up to #730. When rector-src main sits on a release tag commit, that commit is already being published to rectorphp/rector by the tag build. Dispatching a second build makes the two race each other for git push origin main, and the loser fails on a non fast forward push. When the loser is the tag build, it dies before reaching git tag / git push origin <tag>, so the release tag never lands.

         steps:
+            # a tagged main is already being published by the tag build of rector-src,
+            # dispatching a second build would race it for the push to rectorphp/rector
+            -
+                name: "Check whether rector-src main is a release tag commit"
+                id: release_tag
+                run: |
+                    RECTOR_SRC="https://github.com/rectorphp/rector-src.git"
+
+                    MAIN_SHA=$(git ls-remote $RECTOR_SRC refs/heads/main | cut -f1)
+                    if [ -z "$MAIN_SHA" ]; then
+                        echo "Could not resolve rector-src main"
+                        exit 1
+                    fi
+
+                    # lightweight tags are listed with the commit itself, annotated ones with a "^{}" line
+                    if git ls-remote --tags $RECTOR_SRC | grep -q "^${MAIN_SHA}"; then
+                        echo "rector-src main $MAIN_SHA is tagged, leaving the build to the tag itself"
+                        echo "tagged=true" >> $GITHUB_OUTPUT
+                    fi
+
             -
                 name: "Trigger build_scoped_rector.yaml in rectorphp/rector-src"
+                if: steps.release_tag.outputs.tagged != 'true'
                 env:
                     GH_TOKEN: ${{ secrets.ACCESS_TOKEN }}
                 run: gh workflow run build_scoped_rector.yaml --repo rectorphp/rector-src --ref main

Why git ls-remote and not the tags API

git/refs/tags exposes .object.sha, which for an annotated tag is the sha of the tag object, not of the commit, so a comparison against a commit sha silently never matches. rector-src carries 36 annotated tags among 574. The current release tags happen to be lightweight, so the API version would work today and quietly stop working the first time a tag is cut with git tag -a.

git ls-remote --tags lists a lightweight tag with the commit itself and an annotated tag with an extra ^{} line holding the dereferenced commit, so matching on line start covers both. It also needs no token.

The empty MAIN_SHA check is not decoration: without it a failed lookup leaves grep -q "^" matching every line, which would silently skip every future dispatch. Failing loudly is better.

Verified

The step script was run as is against live rector-src:

• main c607ef0, untagged, writes no output, so the dispatch runs
• lightweight tag 2.5.7 (653ec23), detected, writes tagged=true, so the dispatch is skipped
• annotated tag 0.11.39 (771a339), detected through its ^{} line

What this does not cover

A dispatch can still overlap a tag build if a new rector-src commit lands on main after the tag is pushed, since main then no longer points at the tagged commit while the tag build is still running. Closing that fully needs a concurrency: group on build_scoped_rector, which also covers the pre existing push versus push overlap that the workflow already carries a comment about. Separate change, rector-src side.